1. Field of the Invention
The present invention relates to a computer-readable recording medium and an apparatus for processing data based on setting conditions.
2. Description of the Related Art
A printing operation using a printer driver or a facsimile transmission operation using a PC-FAX driver is performed by executing the following processes.
(1) A user displays a printing setting screen by using a printing menu of an application, and sets printing conditions or transmission conditions. It is to be noted that, although the content of the settings of the transmission conditions and the settings of the printing conditions are actually different, both the settings of the printing conditions and the settings of the transmission conditions are hereinafter collectively referred to as “printing setting(s)”.(2) The user instructs printing be started by using the application.
The printer driver receives printing settings determined in the process (1) by way of a database referred to as a DEVMODE structure. Thereby, the printer driver converts document data received from the application into printing data that can be understood by a printer in accordance with the printing settings. The printer driver transmits the printing data to the printer or the facsimile machine. Thereby, printing is performed by the printer and facsimile transmission is performed by the facsimile machine.
In a case where a printer driver or a PC-FAX driver (hereinafter collectively referred to as “printer driver”) receives printing settings from an application, the application notifies the printing settings to a GDI (Graphics Device Interface) of Windows by using an API of Windows. The GDI is a part of a Windows type OS.
The GDI notifies a printing setting instruction to the printer driver by way of the DDI (Device Driver Interface). Because only the I/F of the DDI is defined, each manufacturer (manufacturer of printer driver or PC-FAX driver) can design a method for implementation to the DDI (process performed by the printer driver in a case where the DDI is called).
However, even if a manufacturer uniquely defines an I/F for a printer driver, the I/F cannot be called because the Windows type OS is unable to know the I/F.
1. Regarding DEVMODE Structure
The DEVMODE structure, which stores printing settings therein, is divided into a public area and a private area. FIG. 1 is a schematic diagram for describing an example of a DEVMODE structure. FIG. 2 is a schematic diagram for describing a example of referring to a DEVMODE structure. The public area is an OS definition area. Therefore, an application can change the public area. The public area includes items that every printer driver needs to set such as “printing direction” or “paper size”.
The private area is an area unique to each manufacturer. The private area can define what kind of data is to be stored with respect to a manufacturer or a printer driver. Because the application or Windows type OS is unable to know what kind of data is stored in the private area, the only way to change the private area is to use a UI driver of a printer driver to display the settings in the private area and accept changes to the displayed settings. The private area includes items having characteristics of a manufacturer or characteristics of a printer type such as “printing method” or “authentication”.
The user sets printing conditions (e.g., paper size, number of pages, double-side printing) generated by the UI driver and instructs printing to be performed according to the printing conditions. When the user performs an operation for instructing the setting of printing conditions, an application calls the GDI by making a GDI call and sends the DEVMODE structure to the GDI. The application illustrated in FIG. 2 is an application such as a document generating program (e.g., MS-Word (registered trademark).
When the GDI obtains the DEVMODE structure from the application, the GDI calls a render driver of the printer driver by making a DDI call and sends the DEVMODE structure to the render driver.
The render driver refers to the DEVMODE structure obtained from the GDI, generates printing data complying with the printing settings from the document data instructed to be printed by the application, and sends the generated printing data to a spooler. It is to be noted that plotting data (e.g., PDL data) and control data (e.g., PJL printing command) are included in the printing data.
That is, the UI driver and the render driver can both refer to the DEVMODE structure. Further, the UI driver can display the private area and accept changes of printing settings.
2. Needs for Automation
Accordingly, the only method for changing the private area is to use a printer driver to display a setting screen and accept a user operation(s) performed on the setting screen. Therefore, an operation by the user is required for changing the private area.
However, some processes are desired to be completed fully automatically without requiring any user operation. The processes include, for example, a process of printing forms or a process of transmitting (sending) direct mail (DM) by facsimile. For these processes, operability would be degraded if a user has to change the private area by operating on a setting screen each time of printing a form or transmitting a document by facsimile even in a case where there the printing settings remains the same.
Therefore, there is a desire to be able to change a printing setting stored in the private area of the printer driver to a printing setting suitable for a given application without having to require the user's operation.
In order to fulfill such desire, some manufactures provide an extended I/F of a printer driver, so that an application can directly communicate with the printer driver (see, for example, Japanese Laid-Open Patent Publication No. 2005-148928). Further, applications suitable for a given process are developed to fulfill the user's desire.
FIG. 3 is a schematic diagram for describing an extended I/F, an application, and a DEVMODE structure. The application illustrated in FIG. 3 is an application suitable for a process by the user or an application for calling at least an extended I/F. The application of FIG. 3 calls the extended I/F to change the printing settings in the private area. Accordingly, after the user performs an operation of instructing printing to be started by using the application, printing can be completed without requiring the user's operation.
3. Regarding Printing Settings Stored in DEVMODE Structure
There are some printer drivers that re-display a setting screen after the user has instructed printing to be started, so that changes of printing settings can be accepted before printing data is transmitted.
FIG. 4 is a schematic diagram illustrating an example of re-displaying a setting screen (in this example of FIG. 4, a screen of a confidential printing function). In this example of FIG. 4, input of a user ID and a password is requested by a confidential printing function after printed is instructed to be started by the user. Unless the user inputs a user ID and a password, an OK button 51 cannot be depressed. When the OK button 51 is depressed after the user ID and the password are input, the user ID and the password are transmitted to a printer. A combination(s) of a user ID and a password is registered beforehand in the printer. Accordingly, the printer does not perform printing in a case where the registered combination does not match the transmitted user ID and the password. With this confidential printing function, input of a password may be required each time printing is instructed, so that security can be increased. In a case where the user depresses a cancel button 502, printing is cancelled.
FIG. 5 is a schematic diagram illustrating an example of an address confirmation screen of a PC-FAX driver. The PC-FAX driver displays an address confirmation function screen and requests the user to input an address for facsimile transmission (e.g., facsimile number). In facsimile transmission, the PC-FAX driver displays the screen as illustrated in FIG. 5 for preventing inadvertent transmission in view that the address is often different for each transmission.
When the user inputs the facsimile number and depresses the send button, a facsimile machine performs facsimile transmission by transmitting, for example, image data. In a case where the user depresses a cancel button 504, the facsimile transmission is cancelled.
The settings applied in the examples of FIGS. 4 and 5 are used in cases that require input or confirmation in printing (job) units for the purpose of requesting the user to input a password each time of performing a printing process (so that security is increased) or requesting the user to confirm an designated address each time of performing facsimile transmission (so that inadvertent transmission is prevented).
Being able to change the printing settings after instructing the starting of a printing process means that there is no need to go through a process in which the application determines the printing settings (DEVMODE structure) and instructs execution of a printing process according to the printing settings by way of a UI driver. That is, printing can be performed without referring to the DEVMODE structure by having a render driver obtain and use printing settings that have been changed after instructing the starting of a printing process.
Therefore, the location in which printing settings are stored is not limited to the DEVMODE structure. For example, in an actual PC-FAX driver, printing settings such as facsimile transmission address data are stored in a file or a structure other than the DEVMODE structure. Some printer drivers store all settings in a structure other than the DEVMODE structure.
FIG. 6 is a schematic diagram illustrating an example of printing settings that may be stored outside the DEVMODE structure. For example, address data used during facsimile transmission or personal data used during printing are examples of printing settings that may be stored outside the DEVMODE structure.
Printing settings are not stored in the DEVMODE structure not only for a reason that the printing settings are not needed to be stored in the DEVMODE structure but for other reasons. For example, even if the printing settings can be stored in the DEVMODE structure, there may be a case where the printing settings are intentionally not stored in the DEVMODE structure.
As described above, printing settings may be stored in the DEVMODE structure by the UI driver or reference may be made to the printing settings in the DEVMODE structure by, for example, a graphics driver. In the case of storing printing settings in the DEVMODE structure or referring to the DEVMODE structure, the application is the source that transfers the DEVMODE structure. In reality, in the case of storing the printing settings in the DEVMODE structure, the application secures a memory space, provides the DEVMODE structure to the UI driver by way of the Windows type OS, and embeds data in the DEVMODE structure. In the case of referring to the DEVMODE structure where the application performs printing by way of the Windows type OS, the graphics driver refers to the data in the DEVMODE structure.
Accordingly, in a case where the application does not delete the DEVMODE structure, the printing conditions initially set by the user remains in the DEVMODE structure. Therefore, there is a risk that the file of the DEVMODE structure be transferred to another user. Although most applications delete the DEVMODE structure after a printing process is completed, there are some applications that do not delete the DEVMODE structure even after a printing process is completed.
Therefore, if personal data such as authentication data or a password is stored in the DEVMODE structure, the personal data remaining in a file of the DEVMODE structure could be transferred to an undesired user. This may result to degrading of security. Therefore, there are printer drivers that do not store personal data in the DEVMODE structure.
4. Printing Architecture of Windows Type OS
In performing printing with a printer driver, there are two types of printing architectures of Windows type OS. One is a RAW spool type and the other is an EMF spool type. In a case of printing with the RAW spool type, an application converts document data obtained by a printer driver into RAW data that can be understood by a printer (application process). From a user's standpoint, the user cannot operate the application until a printing process is completed.
In a case of printing with the EMF spool type, an application converts document data obtained by a Windows type OS into EMF data (which is printer independent data) (application process) and spools the EMF data (spooler process). Then, a printer driver converts the spooled EMF data into RAW data that can be understood by a printer. From a user's standpoint, the user can operate the application after the document data is converted into the EMF data.
Both of the above-described architectures can provide a DDI implementing method allows printing settings to be shown by displaying a printing setting screen after printing is started.
5. Point & Print
Next, there is described a relationship between an installing method of a printer driver or a PC-FAX driver and printing settings after printing is started. In the printer drivers of the Windows type OS, there is an installing method called “Point & Print”.
FIG. 7 is a schematic diagram illustrating an example of a system for describing the Point & Print method. In the system illustrated in FIG. 7, a printer, a server PC, and a client PC are connected to a network. A Windows type OS is installed in the server PC and the client PC. The Windows type OS installed in the server PC is an OS dedicated for a server.
The client PC request the printer to perform printing by way of the server PC serving as a print server. In this system, the same printer driver is to be installed in the client PC and the server PC. This leads to a problem in which a large amount of time and workload is required for an administrator or the like to install the printer driver into each client PC in the network.
Point & Print is a method for resolving such problem by allowing a client PC to download and install a printer driver from a server PC. The Point & Print is a function included in a standard Windows type PS. In a printing process using Point & Print, there are both the RAW spool type and the EMF spool type.
In a case where the type of printing architecture is the EMF spool type, the user may change whether a rendering process (process performed by the render driver) should be performed by the client PC or the server PC. A rendering process performed on the client PC side is referred to as “client side rendering” whereas a rending process performed on the server PC side is referred to as “server side rendering”.
6. 64 Bit OS
Under a situation where many users use client PC having a conventional 32 bit OS installed therein, the use of the 64 bit OS is also beginning to spread. The 64 bit OS, as a rule, only operates 64 bit applications. However, the Windows type OS provides a scheme (referred to as WOW 64 (Windows ON Windows 64)) for allowing operation of 32 bit applications that are already sold and distributed.
However, unlike an application, a printer driver is to be generated with 64 bits in the 64 bit OS. Therefore, a 64 bit printer driver is installed in the client PC.
In a case where a 32 bit application is operated with WOW 64, printing is performed in the following manner.
splwow64.exe is operated as the WOW 64.
A render instruction is notified from the 32 bit application to a 64 bit printer driver by way of the splwow64.exe.
In the Windows type OS, there is a scheme in which a “substitute driver” can be installed for sharing a printer (Point & Print). In this system, a printer driver installed in a server is installed in the client PC. In a case where a printer driver compatible to a printer is not installed in the client PC, a suitable printer driver is installed in the client PC. In this case, a 32 bit printer driver can be registered in the 64 bit OS.
However, the above-described conventional technology has the following difficulties.
A. Case of Using an Extended I/F
Even in a case where an extended I/F is used, there is a case where a printing setting cannot be stored.
As illustrated in FIG. 3, when an application changes a printing setting by using an extended I/F (extended by the printer driver), it is necessary of the application to perform the processes of inputting a DEVMODE structure to the extended I/F of the printer driver, receiving an output DEVMODE structure after changing the printing setting, and transferring the received DEVMODE structure to the render driver when printing is started.
In other words, in a case where the extended I/F is used and a printing setting is stored in a location other than the DEVMODE structure, the printer driver is unable to obtain printing settings by way of the extended I/F. Therefore, it becomes necessary to install all printing settings in the DEVMODE structure.
Accordingly, it may be difficult to appropriately implement printing settings in a case where the printer driver is related to personal data or a case where the printer driver determines/changes printing settings after starting of printing is instructed. The printer driver in these cases may be unable to store all printing settings (setting items) in the DEVMODE structure. Therefore, there is a case where printing settings cannot be stored even if the extended I/F is added to the UI driver.
B. Case of Temporarily Storing Printing Settings in a Location Other than the DEVMODE Structure.
In view of the above, there is a printer driver that outputs printing settings to, for example, a file, a registry, or a shared memory space.
FIG. 8 is a schematic diagram illustrating an example for describing a method of storing printing settings in a location other than a DEVMODE structure by way of an extended I/F of a printer driver. In FIG. 8, a part of or all printing settings are stored in a space referred to as “setting storage area”.
With the method described with FIG. 8, it becomes possible to store printing settings that are not stored in the DEVMODE structure, to thereby solve the above-described difficulty of item A. However, by not using the DEVMODE structure, difficulties occur in the following three cases. The three cases include case 1 (which is a case of a printing sequence with an EMF spool), case 2 (which is a case of a printing sequence with a printer driver in which Point & Print is installed), and case 3 (which is a case of using 64 bit OS).
1. Case 1
A method of using a DEVMODE structure, which uses a DDI call sequence during printing, can be executed during RAW spool. However, in a case where a different spool type is used, the DDI call sequence (called by the Windows type OS) changes. The EMF spool includes a process of converting document data from an application into EMF data and a process of converting EMF data into render data that can be understood by a printer. Accordingly, a printing process sequence is performed twice inside the Windows type OS.
However, the twice-performed printing process sequences are performed with different processes with respect to the process of converting document data into EMF data and the process of converting EMF data into render data (RAW data) that can be understood by the printer. In a system such as the Windows type OS, accessibility to a resource is determined by authorization of a process (e.g., system authorization and authorization other than the system authorization). Therefore, depending on the location of a file or registry in which printing settings are stored, it is possible that the printing settings set by the extended I/F cannot be obtained from the stored location when the printer interprets the printing data. Further, with a recent Windows type OS, access may be completely denied if authorization is different from the standpoint of security.
2. Case 2
The method of using an extended I/F can be executed by a method of installing a printer driver to a PC of the user in a local environment.
However, in a case of a printer driver installed by using the above-described Point & Print method, there is a case where an I/F driver and a render driver are operated at different locations (in a case of server side rendering).
In a case of client side rendering, both the UI driver and the render driver operate on the client PC side. However, in a case of server side rendering, the UI driver operates on the client PC side whereas the render driver operates on the server PC side. Because the PCs that are operated are physically different from each other in the case of server side rendering, the printer driver cannot obtain the printing settings that are temporarily stored in the setting storage area (e.g., file, registry) by way of the extended I/F of the printer driver.
3. Case 3
As described above, the WOW 64 is a scheme provided by the Windows type OS, splwow64.exe only operates when printing is performed. Because the Windows type OS does not support a 64 bit extended I/F being accessed by a 32 bit application, splwow64.exe cannot be operated. Therefore, the 32 bit application cannot use a printer driver having the 64 bit extended I/F.
FIG. 9 is a schematic diagram for describing whether it is possible to transfer printing settings in a case where an extended I/F is used. FIG. 9 shows that transferring of printing settings is difficult i) in a case of using the EMF spool where the installation environment is local, ii) in a case of using the EMF spool where the installation environment is Point & Print and the rendering location is the server, and iii) in a case where a 32 bit application is operated in a 64 bit OS.